Predix Services Backup and Retention Policy

Purpose

This document is designed to clarify the policy used by GE Software Predix 2.0 Cloud Services and Operations to archive digitally stored data as a service as well as AWS instance volumes.

Scope

The policy defines the backing up of data and AWS instance volumes from Predix 2.0 Cloud provided by GE Software for use by its customers on AWS-hosted Cloud Foundry, as well as Predix 2.0 Cloud Services and Operations team. Applications or services hosted outside production Cloud Foundry do not fall within the range of these parameters. Cloud Services and Operations team will make recommendations to Predix 2.0 development teams with regard to best practices for archiving data. This policy only refers to production and development related data; end-users should not utilize AWS resources to backup or store personal data.

Policy

Predix 2.0 Cloud Services and Operations team is responsible for automating the backup of data from production and development mysql database instances and Cloud Foundry AWS instance volumes; data backups are stored in AWS S3 and AWS EBS volumes are backed up as volume snapshots. Cloud Foundry AWS instances are: production and development BOSH director – this includes UAADB and CCDB. Data stored in AWS S3 buckets is restricted to database backups. AWS S3 buckets used for data backups have been secured to allow key-only authenticated automated scripts.

Type of Data Environment Host Minimal Backup Policy Backup Retention Policy CF MySQL Database Production 10.202.77.142 Daily at 8PM PST 60 days CF MySQL Database Development 10.202.84.165 Daily at 8PM PST 60 days BOSH Director Production 10.202.75.8 Base plus 6hr Incremental 60 days BOSH Director Development 10.202.94.76 Base plus 6hr Incremental 60 days Procedure

The jump host currently deployed in the GRC VPC, jumpbox_z0_hd, currently stores automated mysql mackup scripts that run as a cron job set to kick off daily at 8PM PST. The script utilizes mysqldump to back up data from both development and production Cloud Foundry MySQL server instances. The script temporarily stores the backups for three days in jumpbox_z0_hd:/data/backups folder and then copies them onto the S3 buckets grc-apps-svc-ice-ge-com-backups and grc-pr-apps-ice-ge-com-backups. A retention policy named mysql_60day_retention_policy is attached to each of the S3 buckets to retain backups no older than 60 days.

BOSH director backups are taken via AWS EBS volume snapshot. Assuming each BOSH director has an EBS volume, namely vol-aaaaa, a full base snapshot of the persistent disk is taken first. This is followed by subsequent incremental 6-hour snapshots. Snapshots are stored in S3 buckets. AWS does not report the EBS volume snapshots in the S3 UI console. The BOSH director VM’s contain the Cloud Foundry UAADB and CCDB postgres databases.

Mysql backup restore is initiated by pulling the backup file from the S3 bucket in which it is stored onto jumpbox_z0_hd, then running a restore mysql command that targets the phpmyadmin host from which the backup was taken. Similarly, to restore the BOSH director box, create a new EBS volume from the snapshot in AWS, then restore BOSH by re-deploying only a selected portion of its deployment manifest.

For more information on MySQL and BOSH backup and restore:

MySQL Backup and Restore

BOSH Backup and Restore

Security Compliance

To be Completed.